System and Method for Efficient Port and Bandwidth Utilization in Setting up Communication Sessions

ABSTRACT

Techniques for efficiently allocating ports and bandwidth in a communication system configured to establish interactive, real time communication sessions between endpoints are described. Requests are received at a server, from a requester endpoint device, to initiate an interactive, real time communication voice and/or video session requiring access to an interactive session resource. In an embodiment, the communication system is a contact center and the interactive session resource is an available contact center agent. Pending availability of the interactive session resource, a requester is assigned a place in a queue or otherwise scheduled to receive access to the interactive session resource. In the meantime, a data channel is established between the server and the requester&#39;s endpoint device. Resources, which can include an executable program and/or information operative to enable the endpoint device to emulate an active on-hold voice connection period, are downloaded to the endpoint device.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/319,107, entitled “System and Method for Efficient Port and BandwidthUtilization in Setting up Communication Sessions,” filed Jun. 30, 2014,which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION 1. Field of the Invention

Embodiments of the disclosure relates generally to establishing andmaintaining communication sessions between two or more endpoints.

2. Description of the Related Art

In communication systems configured to establish interactivecommunication sessions between two or more persons, it is not uncommonfor one, some or all of the persons to be placed on “hold” pending theavailability of an interactive communication session resource. By way ofillustrative example, in a contact center context, a contacting party(e.g. a customer) may use a regular telephone, a smartphone, or a mobileor desktop computer terminal (equipped with a microphone, speakers, userinterface and, optionally, a camera) to request an interactivecommunication session with an agent. In this context, the agent is arequisite interactive communication session resource. If no agent isavailable to speak with or conduct a video conference call with thecontacting party, the contacting party is placed in a queue until anagent does become available.

Web Real-Time Communications (WebRTC) are the result of an ongoingeffort to develop industry standards for integrating real-timecommunications functionality into web clients, such as web browsers, toenable direct interaction with other web clients. This real-timecommunications functionality is accessible by web developers viastandard markup tags, such as those provided by version 5 of theHypertext Markup Language (HTML5), and client-side scripting ApplicationProgramming Interfaces (APIs) such as JavaScript APIs. More informationregarding WebRTC may be found in “WebRTC: APIs and RTCWEB Protocols ofthe HTML5 Real-Time Web,” by Alan B. Johnston and Daniel C. Burnett(2012 Digital Codex LLC), which is incorporated in its entirety hereinby reference.

WebRTC provides built-in capabilities for establishing real-time video,audio, and/or data streams in both point-to-point interactive sessions,as well as multi-party interactive sessions. WebRTC standards have beenjointly developed by the World Wide Web Consortium (W3C) and theInternet Engineering Task Force (IETF). Information on the current stateof WebRTC standards can be found at, e.g., http://www.w3c.org andhttp://www/ietf.org. An example of a communication system configured toemploy WebRTC as part of an interactive communication session betweentwo or more parties is the Contact Center.

In contact center implementations of WebRTC, interactive communicationsession resources (ports, bandwidth reservations, etc.) are frequentlynegotiated and set up between a contact center server and the endpointcommunication terminal used by a contacting party. At some point in thesession flow, WebRTC is used to establish an interactive communicationsession between the contacting party and a contact center agent. TheWebRTC ports and connections are established well in advance of theassignment of an agent, however, because a suitable contact center agentis typically not available right away at the time of contact. While thecontacting party is waiting for a contact center agent, the contactcenter system may stream continuous hold music punctuated by periodicestimated wait time updates over the established communication session,as well as queries for information to be supplied by the contactingparty, and various other announcements to be audibly reproduced bycontacting party's endpoint device.

The thoughtful use of interactive session connections, WebRTC orotherwise, to set up and maintain an interactive conversation with oneor more clients, customers, potential customers, investors, and others,can substantially enrich and enhance the experience for all partiesconcerned. However, as will be appreciated by the contact center“customer on-hold” example discussed above, the resources which must beallocated in order to establish a truly “interactive” communicationsession between endpoints may go unutilized for substantial periods oftime while one of the endpoints is inactive. Since a networkadministrator must provision a network with sufficient resources toaccommodate periods of peak demand, higher costs may be incurred forequipment, software licensing, and/or bandwidth quality of service (QOS)reservations costs than would be the case if these costs were based onactual real-time needs.

A need therefore exists for systems and methods which are able todeliver the same end user experience that can be obtained using aconventional WebRTC session, but with greater efficiency and/or controlover the utilization of bandwidth and resources needed at any giveninstant in time.

SUMMARY OF THE INVENTION

The Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Methods for efficiently allocating ports and bandwidth, in acommunication system configured to establish interactive, real timecommunication sessions between endpoints, are described. According toone or more embodiments, the method receives a request to initiate aninteractive, real time communication session from an endpoint requiringaccess to an interactive session resource, wherein the communicationsession is at least one of a voice or a video session. In an embodiment,the communication system is a contact center and the interactive sessionresource is an available contact center agent. Pending availability ofthe interactive session resource (e.g., a contact center agent), therequester is placed in a queue and a data channel is established betweenthe server and the requester's endpoint device. Resources, which caninclude an executable program and/or information operative to cause theendpoint device to emulate an active on-hold voice connection period,are downloaded to the endpoint device.

In embodiments, a requester's place in a queue is maintained without theneed to maintain a persistent interactive, real-time communicationsession with the requester's endpoint. According to some embodiments,instructions and/or event notifications are periodically exchanged overthe data channel so that the requester's endpoint audibly reproducesmusic-on-hold, advertising messages, announcements, and wait timeestimates according to a locally maintained schedule and using locallystored, rather than streaming content.

In another embodiment, a method of operating an endpoint deviceconfigured to exchange information over a network, the endpoint devicehaving a display, a microphone, and a speaker, comprises sending arequest to initiate an interactive, real time communication sessionrequiring access to an interactive session resource, wherein thecommunication session is at least one of a voice or a video session.Pending availability of the interactive session resource, the methodestablishes a data channel between a server and the endpoint device, andoperates the endpoint device, using information received from theserver, to emulate an active flow of “real time on-hold messages,updates, queries, IVR prompts, and other information.

In another embodiment, a system for establishing contact between aninteractive session resource and an end user comprises one or moreprocessors, and one or more memory devices operatively coupled to theone or more processors and storing computer instructions therein. Theone or more processors are configured to execute at least a portion ofthe program instructions, and the program instructions comprisereceiving a request, at a server configured to administer access to theinteractive session resource, to initiate an interactive, real timecommunication session between an endpoint terminal and the interactivesession resource. The programming instructions further comprise, pendingavailability of the interactive session resource, setting up a datachannel between the server and the endpoint device used by therequester. The program instructions further comprise transmitting to theendpoint device, over the data channel, at least one of an executableapplication or information operative to cause the endpoint device toemulate an active flow of “real time on-hold messages, updates, queries,IVR prompts, and other information pending availability of theinteractive session resource.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a communication system configured todynamically allocate transmission bandwidth and conserve other networkresources by causing endpoints operated by end users to emulate themaintenance of a persistent connection or real time delivery of featuresor services to end users, according to one or more embodiments;

FIG. 2 is a sample event flow diagram depicting communication flows todeliver a bandwidth efficient and resource conserving emulatedexperience to the user of a communication terminal endpoint, accordingto one or more embodiments;

FIG. 3 is a block diagram depicting, in greater detail, the interactionbetween functional components of a communication system constructedaccording to the embodiments exemplified by FIG. 1;

FIG. 4 is a flow diagram depicting a method for dynamically allocatingtransmission bandwidth and conserving other network resources by causingendpoints operated by end users to emulate the maintenance of apersistent connection and/or the real time delivery of features orservices to their devices, according to one or more embodiments;

FIG. 5 is a flow diagram depicting a method for dynamically allocatingtransmission bandwidth and conserving other network resources by causingendpoints operated by end users seeking access to a contact center agentto emulate the maintenance of a persistent connection and/or the realtime delivery of features or services, according to one or moreembodiments;

FIG. 6A is a flow diagram depicting a method for operating an end userendpoint configured to emulate the maintenance of a persistentconnection and/or real time delivery of features by a contact center,according to one or more embodiments;

FIG. 6B is a flow diagram depicting sub-steps associated with one ormore embodiments exemplified by FIG. 6A;

FIG. 7A is a schematic diagram of a browser window on an end userendpoint device, according to one or more embodiments;

FIG. 7B is a schematic diagram of a browser window following invocationof a WebRTC interactive communication session request via a browserclient on an end user endpoint device, according to one or moreembodiments; and

FIG. 7C is a schematic diagram of a notification locally generated by anend user endpoint device, according to one or more embodiments.

While the method and apparatus is described herein by way of example forseveral embodiments and illustrative drawings, those skilled in the artwill recognize that the method and apparatus for dynamically respondingto requests and queries for information relating to one or more eventinvitees or attendees is not limited to the embodiments or drawingsdescribed. It should be understood, that the drawings and detaileddescription thereto are not intended to limit embodiments to theparticular form disclosed. Rather, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the method and apparatus for dynamically responding torequests and queries for information relating to one or more eventinvitees or attendees defined by the appended claims. Any headings usedherein are for organizational purposes only and are not meant to limitthe scope of the description or the claims. As used herein, the word“may” is used in a permissive sense (i.e., meaning having the potentialto), rather than the mandatory sense (i.e., meaning must). Similarly,the words “include”, “including”, and “includes” mean including, but notlimited to.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Systems and methods for dynamically and efficiently allocating ports andbandwidth, preceding the setup of interactive, real time communicationsessions between a requesting endpoint and another endpoint, aredescribed. According to embodiments, such allocation is achieved byemulating the real time delivery of features or services to one or moreend users. According to one or more embodiments, the method receivesrequests to initiate an interactive, real time communication sessionfrom an endpoint seeking access to an interactive session resource,wherein the communication session is at least one of a voice or a videosession. In some embodiments, the requests are WebRTC interactivecommunication session requests received and processed by a contactcenter, and the interactive session resource to which access is soughtby a requester is a connection to the endpoint device of an availablecontact center agent.

Pending availability of the interactive session resource, the end userof an endpoint (“requester”) requesting an interactive communicationsession is either assigned a place in a queue or scheduled for access tothe interactive session resource according to a resource allocationmechanism. In a contact center, for example, queues are maintained by aserver to administer access to agents, in a pool of agents, as theybecome available. According to other embodiments, the interactivesession resource comprises a live interactive communication session witha particular intended recipient, one or more participants in a scheduledconference call, or an investor conference permitting interactive accessto a voice and/or video event hosted by one or more company officials.In the other exemplary applications, there is no need for a queue, perse, insofar as even a large number of end user endpoints can be grantedaccess to an interactive session resource once the session is scheduledto begin. It suffices to say that at the moment when a request isreceived from an end user endpoint, the interactive session resourcesneeded to grant it may not be available.

According to one or more embodiments, the aforementioned unavailabilityis addressed by establishing a data channel between a server and therequester's endpoint device. In WebRTC embodiments, the server itselfserves a data communication “endpoint” for purposes of set up,maintenance and administration of the data channel. Over the datachannel, instructions, data, and/or a file executable (or, simply,“information”) are downloaded from the server and stored locally at therequester's endpoint device. At the beginning of an on-hold period,during which the requester awaits access to the interactive sessionresource, the downloaded information is used by the requester's endpointdevice to emulate an active on-hold voice connection period. That is,content is locally retrieved from the memory of the requester's endpointdevice, and this content is used to generate and audibly and/or visuallyreproduce to the requester a sequence of messages.

The locally retrieved and played and/or displayed content can includemusic-on-hold, wait time updates or updated wait time estimates, generalinstructions, queries for information to be supplied by the end userover the data channel as by a locally displayed IVR menu, and messagesof general interest to a community of persons. According to embodiments,instructions and/or event notifications are periodically exchanged overthe data channel so that the requester's endpoint audibly reproduces themusic-on-hold, advertising messages, announcements, and wait timeannouncements or estimates according to a locally maintained scheduleand using the locally stored, rather than streaming content This allowsa requester's place in a queue (or other access allocation scheme) to bereserved, maintained, and even adjusted. At the same time, the set up ofa persistent interactive real-time communication session, between therequester's endpoint and an endpoint, is deferred until such aconnection is actually needed.

Some portions of the detailed description that follow are presented interms of algorithms or symbolic representations of operations on binarydigital signals stored within a memory of a specific apparatus orspecial purpose computing device or platform. In the context of thisparticular specification, the term specific apparatus or the likeincludes a general-purpose computer once it is programmed to performparticular functions pursuant to instructions from program software.Algorithmic descriptions or symbolic representations are examples oftechniques used by those of ordinary skill in the signal processing orrelated arts to convey the substance of their work to others skilled inthe art. An algorithm is here, and is generally, considered to be aself-consistent sequence of operations or similar signal processingleading to a desired result. In this context, operations or processinginvolve physical manipulation of physical quantities. Typically,although not necessarily, such quantities may take the form ofelectrical or magnetic signals capable of being stored, transferred,combined, compared or otherwise manipulated. It has proven convenient attimes, principally for reasons of common usage, to refer to such signalsas bits, data, values, elements, symbols, characters, terms, numbers,numerals or the like. It should be understood, however, that all ofthese or similar terms are to be associated with appropriate physicalquantities and are merely convenient labels. Unless specifically statedotherwise, as apparent from the following discussion, it is appreciatedthat throughout this specification discussions utilizing terms such as“processing,” “computing,” “calculating,” “determining” or the likerefer to actions or processes of a specific apparatus, such as a specialpurpose computer or a similar special purpose electronic computingdevice. In the context of this specification, therefore, a specialpurpose computer or a similar special purpose electronic computingdevice is capable of manipulating or transforming signals, typicallyrepresented as physical electronic or magnetic quantities withinmemories, registers, or other information storage devices, transmissiondevices, or display devices of the special purpose computer or similarspecial purpose electronic computing device.

Reference will now be made in detail to exemplary embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings. Wherever possible, the same reference numbers will be usedthroughout the drawings to refer to the same or like parts

FIG. 1 is a block schematic diagram depicting a communication system 100configured to dynamically allocate transmission bandwidth and conserveother network resources by emulating the real time delivery of featuresor services to one or more end users of communication devices (“endpoints”) 110 such as smart phones, tablet computers, wearable computers,notebook computers and the like. According to some embodiments, system100 includes an interactive session administration center 102 whichincludes a session emulation module 120 having a session emulationmanager (SEM) 130 and a data repository 140.

Interactive session administration center 102 further includes one ormore voice/data servers as, for example, WebRTC/call servers 150 forestablishing and maintaining interactive communication sessions betweenend user endpoint devices 110 and interactive session resourcesadministered by one or more scheduling servers 160. According to someembodiments, the endpoint devices 110 are configured to perform certainfunctions and to perform those functions at particular times pending setup of a live interactive communication session. At least some of thesefunctions emulate the maintenance of a persistent connection or the realtime delivery of features or services to an end user of the endpoint. Tothis end, endpoint devices 110 are configured to execute a live sessionemulator application 170, which includes local segments 172, dynamicallyconfigurable attributes (“attributes”) 174, and an event listener 176.Other applications typically residing on an endpoint device, especiallyon a mobile terminal such as a Smartphone, tablet or wearable computer,or notebook computer, include a web browser 178 and a telephonyapplication or IP soft phone client 179.

At the time when interactive session administration center 102 receivesa request from endpoint device 110, the aforementioned session emulatorapplication 170 may already installed on the endpoint device 110. Ifnot, then in accordance with some embodiments, SEM 130 retrieves anemulator application installer 122 from data repository 120. A datachannel is set up by server 150 between endpoint 110 and SEM 130, andthe installer is downloaded to and launched by the endpoint device 110.In some embodiments, this data channel is set up in accordance withWebRTC specifications. Even an already-installed instantiation ofemulator application 170 may require up-to-date information foremulating the appropriate user experience, according to someembodiments. To this end and in accordance with such embodiments, SEM130 stores and dynamically updates any configuration information(“information”) 132 needed by session emulator application 176 todeliver an emulated user experience applicable to the end user's currentsession request. The information is sent over the same data channel setup by server 150 between endpoint 110 and SEM 130.

It should be emphasized, and will be readily apparent to the artisan ofordinary skill that other methods and protocols for establishing a datasession or channel may also be utilized, besides WebRTC, may be employedFor example, without regard to whether a locally installed sessionemulation application as application 176 is installed, or whether aclient invoked by browser 178 is used to invoke the same functions via aremote webserver, the data channel need not require any more thanexchange of simple SMS messages between endpoints. Initially, forexample, an SMS setup message may be sent by SEM 130 to the endpointdevice 110. In an embodiment, an SMS setup message includes an hypertextmarkup language (HTML) link to a webserver location. From this location,the user of endpoint 110 can invoked a browser client or commencedownloading, installation and/or launching the emulator application, asthe case may be.

Moreover, it should be further noted that a requester is not limited tothe use of a single endpoint in carrying out various embodimentdescribed herein. For example, according to some embodiments, a usermakes an initial request for a real time interactive communicationsession on a public switched transmission network (PSTN) using a firstendpoint such as a voice-only standard telephone, but establish asubsequent data session as described in embodiments herein via a secondendpoint device such as a Smartphone or other device having theattributes and functionality of an endpoint device as device 110. Insuch embodiments, a failure to maintain the PSTN connection during an“on-hold period” does not result in the calling party's place in aqueue. Rather, the data channel is maintained and when the interactivecommunication resource(s) become(s) available, a new call to theoriginal PSTN endpoint can be placed or the calling party can continueto use the second endpoint.

The information 132 typically includes one or more media segmentsretrieved from segment datastore 124 of data repository 120, as well asinstructions pertaining to the order in which those segments should beaudibly reproduced and/or visually displayed to the end user's endpointdevice 110 as part of the emulated user experience. In contact centerapplications, such dynamically variable attributes as currentlyestimated wait time can also be included as part of information 132.Event listener instructions 176 and 134, forming part of the emulatorapplication 170 and SEM 130, respectively, detect and report statechanges associated with device 110 and server(s) 160, respectively.Responsive to a change in state or availability of the endpoint 110 or aresource administered by server 160, as the case may be, one or moredynamically variable attributes are updated by SEM 130 and instructionsfor endpoint 110 to update the attribute(s) are sent by SEM 130 over thedata channel established by server 150.

FIG. 2 is a sample event flow diagram depicting communication flows todeliver a bandwidth efficient and resource conserving emulatedexperience to the user of a communication terminal endpoint, accordingto one or more WebRTC embodiments of the system 100 depicted in FIG. 1.As seen in FIG. 2, an end user device 110 executing a web client such asa browser navigates to a web page and initiates a request 201 toestablish a WebRTC interactive communication session with an endpointadministered by a WebRTC interactive session resources servers 150-160.Initially, only a WebRTC data connection (“channel”) 51 (FIG. 1) is setup, between a server (e.g. 150 or 160) and endpoint 110. If the emulatorapplication 170 is not yet installed on the endpoint 110, it isdownloaded 204 from datastore 120 via a webserver, and then launched onthe endpoint 110.

A notification 205 that the emulator 170 has been launched istransmitted over the data channel, and SEM 130 sends 206 configurationinstructions to the emulator application 170. In accordance with aprescribed order set by the configuration instructions received from SEM130, emulator application 170 sends instructions 211-214 causing a webclient of endpoint 110 to retrieve and play and/or display locallystored media content furnished earlier (i.e., not in “real time”) by SEM130. An event listener associated with emulator application 170 receivesan unavailability event state transition notification 215 from endpointdevice 110, indicating that the end user of device 210 would beunavailable if an interactive communication session were to begin duringthe corresponding event. By way of example, the end user may receive andaccept a phone call, or initiate one, using an IP telephony client,while waiting for an interactive WebRTC communication system to begin.In such event, the end user does not lose his or her place in a queue orreservation to an upcoming interactive event. Instead, emulatorapplication 170 transmits an unavailability state change notification at216 to SEM 130, and SEM 130 forwards the notification as an updatenotice 217 to a scheduling or queue manager agent (not shown) ofscheduling server 160. In some embodiments, the event listener is notalways active, but responds to a trigger request, originating from theinteractive communication system, indicative of imminent availability ofthe requested interactive communication resource to the user of endpoint110.

Responsive to state change transition notification 216, schedulingserver 160 transmits a corresponding reservation update notification217, if appropriate to SEM 130. In some non-contact center embodiments,the reservation is unaffected by an unavailability state change.Consider, for example, that an event such as a shareholder meeting,multi-participant webinar, or online education class may employ aserver, associated with scheduling server 160, as one WebRTC endpoint tofacilitate a “live” interactive communication session comprising manypeer to peer WebRTC communication sessions. In some embodiments, whensuch a multi-participant event begins, WebRTC interactive communicationresources are reserved for the unavailable user and a notification (notshown) is sent, via SEM 130, to the emulator application 170 to alertthe end user that the event has commenced. A message may, for example,be displayed automatically to the endpoint 110 at the initiation of theemulator application 170 (e.g., rendered to the web client userinterface) in order to notify the end user that he or she may join theconference when he or she is ready.

In other embodiments, however, where the intended interactive session isto be between two individuals as, for example, in a contact center orpeer-to-peer telephony scenario, scheduling server 160 responds toupdate notice 217 by transmitting an update attributes notification 218to SEM 130. Such attributes are, in some embodiments, the means by whichthe emulator application 170 is dynamically updated to accommodate anupdated state change. By way of illustration, the attributes may specifya new announcement or menu to be displayed to the end user or that anexisting message stored in memory of device 110 be updated or modifiedto include a new hold message wait time.

In any event, and with continued reference to the embodiment of FIG. 2,it will be seen that a notification 219 of an availability state eventtransition (e.g., the termination of an IP telephony or Skype call) isreceived by the event listener of emulator application 170 and anotification of the state change 220 is transmitted by emulatorapplication 170 over the data channel 51 (FIG. 1) to SEM 130. Updatenotice 221 from SEM 130 is received by scheduling server 160 which, inthe illustrative example of FIG. 2, is now able and ready to makeinteractive communication session resources available to the user ofendpoint device 110. To this end, a resources available notification 222is sent by scheduling server 160 to the SEM 130, and a “live” WebRTCinteractive communication session (i.e., an audio and, optionally videochannel) 224 is initiated between a resource administered by schedulingserver 160 and the endpoint device 110.

According to some contact center embodiments, the SEM is configured toperform certain on-hold emulation functions which are implemented in aspecialized instantiation of a SEM referred to herein as a hold sessionemulation manager or simply, an “HSEM”. According to some embodiments,an HSEM is programmed to:

-   -   enable the Web browser of a user who initiates a WebRTC contact        center request to emulate certain features and functions        heretofore performed “in real time” by the contact center via a        reserved open channel. These functions can include playback of        hold music, status messages or other messages, as well as        audible reproductions of menu prompts. To accomplish this        without reserving a continuously active “voice” channel, the        HSEM downloads a “setup” file to the user's endpoint over a data        channel or provides the user with instructions for downloading        the application from a webserver;    -   in some embodiments, the setup file includes the hold music,        messages, or prompts to be played, with a session emulator        application program adapted to cause any of the foregoing to be        played to the caller in accordance with instructions. The same        data channel can be used to update or replace any of the        messages during the course of the call, and/or to alter the        manner in which they are audibly reproduced, and to transfer        control of the session back to the contact center at the        appropriate time. In this way, resources are conserved and freed        up at the contact center side during the time the caller is        waiting to be connected to an agent (i.e., before support for a        “real time” conversation between agent and caller becomes        necessary).    -   for users that prefer a virtual queue/callback model, a WebRTC        data session (“channel”) established to support hold session        emulation, according to embodiments, can remain active and        monitor if the user is free/available. The user could also        indicate to the scheduling function of a contact center the        user's current intentions (e.g., via an off/on switch on the web        page through which the WebRTC session is launched). This        information can be taken into account when connecting the user        to the contact center agent. Note that no explicit outbound call        is needed in this scenario: the WebRTC session is connected to        the contact center agent at the correct time.    -   a distinctive feature of some embodiments is that the user        remains connected to a contact center, during the entirety of a        hold session, via a low-cost data channel that transmits        keep-alive and other low bandwidth control/metadata (e.g., via        web sockets) with the contact center. A user may terminate the        entire session, or save the session to continue it later, using        the data channel.    -   a further aspect of one or more embodiments is the ability to        automatically influence the scheduling of the actual live        customer/call center connection based on other sessions that the        user may have open in the browser. Specifically, if the user of        an endpoint receives an incoming WebRTC call and wishes to        prioritize this call over the virtual connection with the call        center (i.e. by accepting the incoming call), the establishment        of the live call center connection can be delayed until the        incoming call session has terminated. Likewise, if the user        places a WebRTC call while waiting for the call center        connection, the latter is rescheduled at least until the former        is completed. Additional session prioritization is possible: for        example, if the user is actively (and furiously) typing a        document in a cloud-based word processor, this session may be        prioritized over the call center session and the establishment        of the call center connection can be delayed until the user's        interaction with the word processor has decreased below a        certain activity threshold.

When a contact center agent becomes available for assignment to therequester, the requester may not be available for the intendedcommunication. This may be true even if the requester endpoint has notdetermined any obvious requester unavailability (concurrent WebRTC call,furious typing, etc.). The requester's endpoint can aid in determiningthe requester's availability in such a case: the endpoint can pop up aform with several user-selectable choices for the desired start of thecommunication session, such as “Ready to communicate”, “Ready tocommunicate shortly”, “Need extra time”, “Cancel”, etc. The list ofchoices is part of the initial download to the user endpoint and can bedynamically adjusted at download time and during the wait time dependingon current contact center conditions (hours of operation, current agentpool, agent utilization, etc.). When the requester chooses from the listof communication start options, the choice is transmitted to the contactcenter. It results in one of several possible actions both in theendpoint and in the server. For example, for “Ready to communicate now”it would the immediate establishment of a WebRTC connection betweenboth. For “Ready to communicate shortly”, the connection may be delayedby one minute. For “Need extra time”, the agent would be returned to thepool of available agents and when the next agent is available, therequester would again receive the same popup.

FIG. 3 is a block diagram depicting the interaction between thefunctional components of a contact center system 300 according toembodiments exemplified by the generalized system of FIG. 1. The variouscomponents of system 300, including server 302, switch/media gateway350, interactive voice response (IVR) system 352, WebRTC Call/DataServer 360, agent scheduler 362, and agent devices 381-383. Thesecomponents are connected to one another, and to user communicationterminals (endpoints) 310, by one or more network links. Some of thelinks are established by a network which includes a communication systemthat connects computers (or devices) by wire, cable, fiber optic and/orwireless link facilitated by various types of well-known networkelements, such as hubs, switches, routers, and the like. The networkinterconnecting some components may also be part of the Intranet usingvarious communications infrastructure, such as Ethernet, Wi-Fi, apersonal area network (PAN), a wireless PAN, Bluetooth, Near fieldcommunication, and the like.

The various servers 302, 350 and 360 are each a computing device, or maybe the same computing device as, for example, a desktop computer,laptop, tablet computer, and the like, or they may be cloud basedservers e.g., a blade server, virtual machine, and the like. Interactiveaccess to each of Agents 1-n, each associated with a corresponding oneof devices 381, 382 and 383, respectively, is administered by agentscheduling server 362. WebRTC voice connections are established betweena user endpoint, as endpoint 310, and one of the agent endpoints 381-383administered by WebRTC call server 360.

Prior to establishing a WebRTC voice connection between theaforementioned endpoints, however, contact center system 300 isconfigured to emulate hold sessions using the data channel capabilitiesof WebRTC servers, as opposed to sending a stream of packets ready to beaudibly reproduced as they arrive or after buffering. To this end,according to some embodiments, server 302 includes a hold sessionemulation manager (HSEM) comprising a set of instructions residing inmemory 308 and executable by a Central Processing Unit (CPU) 304. TheCPU 304 may include one or more commercially available microprocessorsor microcontrollers that facilitate data processing and storage. Varioussupport circuits 306 facilitate the operation of the CPU 304 and includeone or more clock circuits, power supplies, cache, input/outputcircuits, and the like. Support circuits 306 also include networkinterfaces for establishing connections between other components (e.g.agent scheduling server 362) of contact center 300. The memory 308includes at least one of Read Only Memory (ROM), Random Access Memory(RAM), disk drive storage, optical storage, removable storage and/or thelike. In addition to hold session emulation manager 330, memory 308includes an operating system 309.

As in the generalized SEM 130 depicted in FIG. 1, HSEM 330 includesinformation 332, comprising instructions 336 and session attributes withthe latter being organized as session attribute profiles 338. Accordingto some embodiments, a session attribute profile includes segments (e.g.media content, graphic files, and other data) to be downloaded to andlocally stored at the endpoint devices 310, and specific data attributesidentifying, for example, a specific playback or presentation order tobe executed by the endpoint device. As another example, a set ofspecific numeric hold times in minutes as, for example, the set ofvalues {“9”, “4”, “1” } could be sent from HSEM to the endpoint device310. These values signify that the same audio segment locally stored inthe memory of the endpoint device 310 such, for example, as “we nowestimate your time on hold to be another {______} minutes” could bemodified three separate times for playback, at discrete points in timeduring a simulated hold session. Alternatively, three separate mediafiles each corresponding to a different one of those three estimates,might be retrieved and/or presented visually to the end user of endpoint310 in a particular order specified by the instructions 336. It sufficesto say, that with an appropriate emulator program configured to processthe instructions 336 and profiles 338, a highly customizable and featurerich on-hold experience can be presented to an end user without tying upWebRTC interactive voice and/or video communication resources.

HSEM 330 further includes an event listener 334, which enables theaforementioned data attributes and instructions to be dynamicallymodified, as necessary in response to state changes such, for example,as the availability of the user of endpoint device 310 on the one handand revision of hold time estimates by agent schedule 362 on the other.A data repository 320, which may reside at a webserver situated remotelyrelative to HSEM 330, comprises a segment data store 324 which includeshold session media files 326 as well as announcements and other content328 available for download to endpoints 310. The data repository furtherincludes an installer 322, by which any endpoint device invoking aconnection to the WebRTC server can retrieve, install and configure thehold session emulation application if it is not already have theapplication installed.

Turning now to the end user communication terminals or endpoint devicesthemselves, it will be seen from FIG. 3 that each endpoint device 310 isa computing device, for example a desktop computer, notebook, tabletcomputer, Smartphone, wearable computer or the like that includes or isconnected to a display and also includes user input devices such as amouse, keyboard, touch screen, camera, microphone, etc. In theillustrative embodiment of FIG. 3, the user endpoint device 310 is acomputer tablet that includes a Central Processing Unit (CPU) 311,support circuits 312, a memory 313, as well as a network interfaceadapted to communicatively couple terminal 310 to server 302 via one ormore wireless internet connections or other network connections.

CPU 311 includes one or more commercially available microprocessors ormicrocontrollers that facilitate data processing and storage. Thevarious support circuits 312 facilitate the operation of CPU 311 andinclude one or more clock circuits, power supplies, cache, input/outputcircuits, and the like. The memory 313 includes at least one of ReadOnly Memory (ROM), Random Access Memory (RAM), disk drive storage,optical storage, removable storage and/or the like. The memory 313includes an operating system 314 that provides a computing foundationfor software applications of the user endpoint device 310. The memory313 includes applications such as a browser 378, for invoking a clientconfigured to request initiation of a WebRTC interactive communicationsession to one of the aforementioned agent endpoints 381-383administered by WebRTC call server 360. Other applications residing inmemory of endpoint devices 310 include an IP soft phone client 379, andin accordance with one or more embodiments, session emulator application370.

As already noted, in accordance with some embodiments, the endpointdevices 310 are configured to perform certain hold session functions andto perform those functions at particular times pending set up of a liveinteractive communication session. In some embodiments, the functionsinclude, at any given point in time, audible playback of music-on-hold,announcements and/or advertising messages, and queries for informationto be provided by the user, as well visual display of announcements,display of IVR prompts and/or queries, and the like. To initiate suchfunctionality, the live session emulator application 370 is eitherdownloaded to and launched by the endpoint 310, or if it is alreadythere, it is launched.

As part of the information accompanying the installer for application370, which includes local segments 37 (media files, scripts, images),dynamically configurable attributes (“attributes”) 174, and an eventlistener 176. Other applications typically residing on an endpointdevice, especially on a mobile terminal such as a Smartphone, tablet orwearable computer, or notebook computer, include a web browser 178 and atelephony application or IP soft phone client 179.

FIG. 4 is a flow diagram depicting a method 400 for dynamicallyallocating transmission bandwidth and conserving other network resourcesby causing endpoints operated by end users to emulate the maintenance ofa persistent connection and/or the real time delivery of features orservices, according to one or more embodiments. The method 400 isapplicable to the generalized communication system 100 depicted inFIG. 1. The method is entered at step 402 and proceeds to step 404. Atstep 404, the method receives a request from an endpoint device user toset up an interactive WebRTC session. The method proceeds todetermination step 406.

At step 406, a determination is made by the method 400 as to whether aninteractive session resource is available and, if not, the methodadvances to step 408. At step 408, the end point user is assigned to aqueue or scheduler and, pending availability of the interactive sessionresource, the method advances from there to step 410. At step 410, themethod opens a WebRTC data connection (channel) and, at determinationstep 412, determines whether a session emulator is already stored andexecutable by the requesting endpoint. If not, the method 400 advancesto step 414 where the method prompts the user to consent to the downloadand installation of the local emulator application. The process proceedsto determination step 416.

It should again be emphasized that although embodiments have beenillustrated and described by reference to an emulator applicationdownloaded, installed, and launched with the consent of an endpointuser, other options are contemplated herein. In modified embodiments,steps 410-416 may be replaced by an event flow in which the user of therequesting endpoint is prompted by an SMS message to click on a linkestablishing a web browser connection to a webserver which delivers thesame content and functionality as the local emulator application. Theweb browser client captures and reports event state transitions to thewebserver for relay to the remote SEM, and performs all necessaryprocesses (display of prompts, menus, options, messages, and playback ofmedia) as necessary to provide the same user experience as wouldotherwise be delivered if a local emulator application were beingexecuted.

At determination step 416, if the end user does not consent toinstallation of the local emulator application, the method 400 proceedsto step 418 and sets up a “real” hold session by establishing a WebRTCreal time voice communication connection to the user endpoint and, atstep 420, transmitting a “live” content stream to the end user via thisconnection. The process advances to determination step 422 where method400 determines whether interactive session resources are available tothe end user receiving the live “hold session” content stream. If not,the method 400 returns to step 420 and continues to send theaforementioned live content stream. If, on the other hand, theinteractive session resource is available, then the method advances tostep 424, the resource is selected, and the method advances to step 426where an interactive WebRTC connection is established between theendpoints associated with the interactive session resource and therequesting end user, respectively.

If, at determination step 406, it is instead determined that an endpointassociated with the interactive session resource were available forconnection to the end user, method 400 advances directly to step 438,reserves the resources for an interactive WebRTC interactivecommunication session, and then proceeds to step 424 as previouslydescribed.

If, at determination step 412, method 400 determines that the localsession emulator application is installed on the end user's endpointdevice, or if at determination step 416 the end user consents todownloading and installation of the local session emulator application,the method 400 advances to 430. At step 430 the local emulatorapplication is either installed and launched, or if it alreadyinstalled, then it is launched. The method 400 proceeds to step 432, andbegins listening for events indicative of, for example, an availabilitystate change or other notification from sent by the local emulatorapplication. The method then proceeds to step 434 and transmitsinformation (e.g., instructions, data attributes, and updated mediacontent for future presentation/replay) to the end user endpoint. Themethod proceeds to determination step 436.

At step 436, the method 400 determines whether the interactive sessionresource requested is available. If not, the method returns to step 432and continues listening for event transitions or updates from theemulator application and/or the scheduler for the interactive sessionresource. Once the resource becomes available, the method 400 advancesto step 438, and reserves resources and a connection for the WebRTCinteractive communication session between the end user and thenow-available interactive communication session resource. The methodproceeds to step 424 and proceeds from there as already described.

FIG. 5 is a flow diagram depicting a method 500 for dynamicallyallocating transmission bandwidth and conserving other network resourcesby causing endpoints operated by end users seeking access to a contactcenter agent to emulate the maintenance of a persistent connectionand/or the real time delivery of features or services, according to oneor more embodiments. The method 500 is applicable to embodiments of acontact center 300 exemplified by FIG. 3. The method 500 is entered atstep 502 and proceeds to step 504. At step 504, the method receives arequest from an endpoint device user to set up an interactive WebRTCsession between the endpoint user and a contact center agent. The methodproceeds to determination step 506.

At step 506, a determination is made by the method 500 as to whether anagent is available and, if not, the method advances to step 508. At step508, the end point user is assigned to an agent selection queue and,pending availability of the agent associated with a WebRTC endpoint, themethod advances from there to step 510. At step 510, the method opens aWebRTC data connection (channel) and, at determination step 512,determines whether a session emulator is already stored and executableby the requesting endpoint. If not, the method 500 advances to step 514where the method prompts the user to consent to the download andinstallation of the local emulator application. The process proceeds todetermination step 516.

At determination step 516, if the end user does not consent toinstallation of the local emulator application, the method 500 proceedsto step 518 and sets up a “real” hold session by establishing a WebRTCreal time voice communication connection to the user endpoint and, atstep 520, transmitting a “live” content stream to the end user via thisconnection. The process advances to determination step 522 where method500 determines whether end user's place in the queue is now such that anagent is presently available to the end user receiving the live “holdsession” content stream. If not, the method 500 returns to step 520 andcontinues to send the aforementioned live content stream. If, on theother hand, the agent is available, then the method advances to step524, the agent is selected, and the method advances to step 526 where aninteractive WebRTC connection is established between the endpointsassociated with the agent and the requesting end user, respectively.

If, at determination step 506, it is instead determined that an agent isavailable for connection to the end user, method 500 advances directlyto step 538, reserves the resources for an interactive WebRTCinteractive communication session, and then proceeds to step 524 aspreviously described.

If, at determination step 512, method 500 determines that the localsession emulator application is installed on the end user's endpointdevice, or if at determination step 516 the end user consents todownloading and installation of the local session emulator application,the method 500 advances to 530. At step 530, the local emulatorapplication is either installed and launched, or if it alreadyinstalled, then it is launched. The method 500 proceeds to step 532, andbegins listening for events indicative of, for example, an availabilitystate change or other notification sent by the local emulatorapplication. The method then proceeds to step 534 and transmitsinformation (e.g., instructions, data attributes, and updated mediacontent for future presentation/replay) to the end user endpoint. Themethod proceeds to determination step 536.

At step 536, the method 500 determines whether end user's place in thequeue is such that an agent is now available. If not, the method returnsto step 532 and continues listening for event transitions or updatesfrom the emulator application and/or the agent scheduler. Once an agentbecomes available, the method 500 advances to step 538, and reservesresources and a connection for the WebRTC interactive communicationsession between the end user and the now-available agent. The methodproceeds to step 524 and proceeds from there as already described.

FIG. 6A is a flow diagram depicting a method 600 for operating an enduser endpoint configured to emulate the maintenance of a persistentconnection and/or real time delivery of features by a contact center,according to embodiments. The method 600 is entered at step 602 andproceeds to step 604. At step 604, the method transmits a request,typically by launching a browser client via an endpoint such as a mobileterminal (e.g. Smartphone, tablet computer, or notebook computer), for aWebRTC voice or other interactive communication session with a contactcenter agent. The method 600 proceeds to determination step 606.

At determination step 606, the method determines whether or not an agentis currently available. If not, the method proceeds to step 608 andcauses an on-hold message to be displayed on the end user's endpointdevice. The method proceeds to step 610 and opens a WebRTC dataconnection between the contact center and the endpoint. At step 612, themethod determines whether a local session emulator application isalready installed on the user's endpoint. If not, the method 600proceeds to 614 and displays a prompt to the display of the endpoint,inviting the user to consent to the download and launch of an installer.The method proceeds to step 616 and determines whether or not the enduser agrees to the download and installation. If not, the methodproceeds to step 618 where resources for a conventional interactiveWebRTC communication session are allocated for a connection between thecontact center and end user's terminal, and a “live on-hold session” isestablished therebetween. During sessions of this type, the methodreceives at step 620 a real time stream of packets used by the browserof his or her endpoint to generate real-time audio and/or video updates,as well as IVR functionality (queries and response handling, etc.). Atstep 622, the method determines whether or not the end user's place inthe queue is such that an agent is available and, if so, the methodproceeds to step 638, wherein the interactive connection to an agentendpoint is initiated and voice data is exchanged via an interactiveWebRTC peer-to-peer connection.

If, at determination step 606, it is instead determined that an endpointassociated with an agent is presently available for connection to theend user, method 600 advances directly to step 638, reserves theresources for an interactive WebRTC interactive communication session,and then proceeds to step 636 as previously described.

If, at determination step 612, method 600 determines that the localsession emulator application is installed on the end user's endpointdevice, or if at determination step 616 the end user consents todownloading and installation of the local session emulator application,the method 600 advances to 628. At step 628, the local emulatorapplication is either installed and launched, or if it alreadyinstalled, then it is launched. The method 600 proceeds to step 630, andbegins listening for events indicative of, for example, an availabilitystate change or other notification sent by the local emulatorapplication. The method then proceeds to step 632 and receives, from thecontact center, information (e.g., instructions, data attributes, andupdated media content for future presentation/replay) at the end userendpoint. The method proceeds to determination step 634.

At step 634, the method 600 determines whether the end user's place inthe queue is such that an agent is now available. If not, the methodreturns to step 630 and continues listening for event transitions orupdates based on activity associated with other applications executingon the endpoint device and/or the agent scheduler. Once a notificationis received from the contact center indicating that an agent has becomeavailable, a determination that an agent is available is made at step634 and the method 600 advances to step 636. At step 634, a WebRTCconnection between the end user and the now-available agent isestablished. The method proceeds to step 638 and proceeds from there asalready described. For all event flows, the method terminates at step626.

FIG. 6B is a flow diagram depicting sub-steps associated with one ormore embodiments exemplified by FIG. 6A. Specifically, the sub-stepscomprising 630 and 632 according to one or more embodiments are shownand will now be described. From step 628, the step 630 of method 600proceeds to sub step 640, where the method 600 receives initialinstructions from the hold session emulation manager (HSEM). The methodproceeds to step 642 and configures the data attributes of the localemulator application according to instructions received from the HSEMor, in the absence of such instructions, by a default configurationestablished at installation. The method 600 proceeds to determinationstep 644.

At determination step 644, the method determines whether a local event,such as an availability state transition (e.g. a telephony “off hook”event) has been detected by the local emulator app. If not, the method600 proceeds to step 646, wherein playback of a first locally storedsegment (e.g., a selection of on-hold music) is audibly reproduced bythe end user's endpoint device. Alternatively, or in addition, theuser's device may, at step 646, retrieve and display a locally storedIVR menu to the user's device, and/or display an audio equivalent ofthis IVR menu as the first segment. The method advances to step 648where a next local segment (e.g. a wait time update) is played forand/or displayed to the end user using content locally accessed by theuser's endpoint device. From here, the method proceeds to step 634 (FIG.6A).

If a local event was detected at step 644, the method proceeds to step650 and transmits an event state notification message to the HSEM. Atdetermination step 652, the method determines whether any newinstructions—as might have resulted from any event(s) reported at step650—have been received from the HSEM. If not the method 600 proceeds tostep 648. If so, however, the method returns to step 642 and updates thelocal emulator application and any associated attributes to carry outthe new HSEM instruction(s).

From FIG. 6A, it will be recalled that at determination step 634, if anagent is not yet available, the method 600 returns to step 630 andcontinues to listen for events and/or exchange state information withthe HSEM. In some embodiments, an intermediate sub-step 654 (FIG. 6B) isautomatically performed by the local emulator application. For example,in embodiments where the emulator is configured to play a specificsequence of audible segments, the method may select the next segment ina sequence or modify one of the segments according to an updatedattribute. Thus, for example, if a wait time update containing an “eightminutes remaining update was played by the end user's endpoint device ina previous iteration of step 648, at step 654 the next local segment tobe played at step 648 three minutes later might be decremented to a“five minutes remaining” estimate (unless a contrary instruction wasreceived from the HSEM overriding such a subsequent update value).

FIG. 7A is a schematic diagram of a browser window 700 on the display315 of an end user endpoint device 310, according to one or moreembodiments. In the example shown in FIG. 7A, the user of endpointcommunication terminal 310 is presented with an option of initiating aconnection to an agent via pop-up window or button 702. Other optionspresented in the example of FIG. 7A include are navigation buttons 704,to navigate back to a prior window, and 706, to add a displayed productitem to a shopping cart.

FIG. 7B is a schematic diagram of the browser client window 700,featured on display 315, following invocation of a WebRTC interactivecommunication session request. When the browser client invoking theconnection is executed on the end user endpoint device 310, according toone or more embodiments, the user is presented with a notification 707that a local emulator application (identified as a “Customer SupportApplication” in the exemplary embodiment of FIG. 7B), will now beinstalled to the endpoint device. At this point the user may eitherconsent to the installation by clicking (or touching) the feature button708 or reject the installation by clicking (or touching) the featurebutton 710. Likewise, a user wishing to learn more before making adecision uses feature button 712.

FIG. 7C is a schematic diagram of a notification locally generated by anend user endpoint device, according to one or more embodiments. In theexemplary embodiment of FIG. 7C, the browser client, by local executionof the local session emulator program by a processor of the userendpoint device 310, has visually presented a locally generated menu tothe display 315 of the device 310 and collected the user's response(“HOME” use) over the established WebRTC data channel. However, thelocal event listener associated with the local emulator program hasdetected that the user has accepted an IP telephony call on his or herendpoint device. As a result, a notification 718 is displayed to theuser indicating that the user's place in a queue has not yet beenaffected by this development. The user is given the opportunity toacknowledge the notification by touching or clicking on a displayedfeature button 720. According to embodiments, the detection of the eventand generation of the displayed notification are performed solely by theemulator program without the need for further exchange of informationwith the contact center HSEM. In other embodiments, the state change isreported but no further actions are taken by the local emulator programunless and until a need arises to prompt the user for furtherinformation. In some embodiments, the user may continue to be presentedwith locally stored, retrieved and displayed query menus such as the onedepicted in FIG. 7C, and hold music and/or audible wait time updatessuspended in favor of visual updates for the duration of the user'stelephone call.

The embodiments of the present invention may be embodied as methods,apparatus, electronic devices, and/or computer program products.Accordingly, the embodiments of the present invention may be embodied inhardware and/or in software (including firmware, resident software,micro-code, etc.), which may be generally referred to herein as a“circuit” or “module”. Furthermore, embodiments may take the form of acomputer program product on a computer-usable or computer-readablestorage medium having computer-usable or computer-readable program codeembodied in the medium for use by or in connection with an instructionexecution system. In the context of this document, a computer-usable orcomputer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.These computer program instructions may also be stored in acomputer-usable or computer-readable memory that may direct a computeror other programmable data processing apparatus to function in aparticular manner, such that the instructions stored in the computerusable or computer-readable memory produce an article of manufactureincluding instructions that implement the function specified in theflowchart and/or block diagram block or blocks.

The computer-usable or computer-readable medium may be, for example butnot limited to, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, device, or propagationmedium. More specific examples (a non-exhaustive list) of thecomputer-readable medium include the following: hard disks, opticalstorage devices, a transmission media such as those supporting theInternet or an intranet, magnetic storage devices, an electricalconnection having one or more wires, a portable computer diskette, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,and a compact disc read-only memory (CD-ROM).

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language,such as Java®, Smalltalk or C++, and the like. However, the computerprogram code for carrying out operations of the present invention mayalso be written in conventional procedural programming languages, suchas the “C” programming language and/or any other lower level assemblerlanguages. It will be further appreciated that the functionality of anyor all of the program modules may also be implemented using discretehardware components, one or more Application Specific IntegratedCircuits (ASICs), or programmed Digital Signal Processors ormicrocontrollers.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. For example,although the exemplary embodiments have use WebRTC to initiate real timeinteractive communication sessions between two or more endpoints, suchis by way of illustrative example only. Other techniques such, forexample as Adobe Flash are equally applicable and capable of carryingout the objective of receiving and processing request to set up a realtime interactive communication session. It should therefore beappreciated that the embodiments were chosen and described in order tobest explain the principles of the present disclosure and its practicalapplications, to thereby enable others skilled in the art to bestutilize the invention and various embodiments with various modificationsas may be suited to the particular use contemplated.

The methods described herein may be implemented in software, hardware,or a combination thereof, in different embodiments. In addition, theorder of methods may be changed, and various elements may be added,reordered, combined, omitted, modified, etc. All examples describedherein are presented in a non-limiting manner. Various modifications andchanges may be made as would be obvious to a person skilled in the arthaving benefit of this disclosure. Realizations in accordance withembodiments have been described in the context of particularembodiments. These embodiments are meant to be illustrative and notlimiting. Many variations, modifications, additions, and improvementsare possible. Accordingly, plural instances may be provided forcomponents described herein as a single instance. Boundaries betweenvarious components, operations and data stores are somewhat arbitrary,and particular operations are illustrated in the context of specificillustrative configurations. Other allocations of functionality areenvisioned and may fall within the scope of claims that follow. Finally,structures and functionality presented as discrete components in theexample configurations may be implemented as a combined structure orcomponent. These and other variations, modifications, additions, andimprovements may fall within the scope of embodiments as defined in theclaims that follow.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof, and the scope thereof isdetermined by the claims that follow.

What is claimed is:
 1. A method comprising: receiving a request at aserver, from a requester endpoint device, to initiate an interactivereal-time communication session, wherein the request was transferred inresponse to user input into a browser executing on the requesterendpoint device; after receiving the request, transmitting an emulatorapplication to the requester endpoint device, wherein the requesterendpoint device executes the emulator application; receiving a report ofan event detected by the emulator application on the requester endpointdevice; and in response to the event indicating new instructions shouldbe sent, updating the emulator application with the new instructions,wherein the emulator application is updated to carry out the newinstructions.
 2. The method of claim 1, further comprising: in responseto receiving the request, determining that an interactive sessionresource is not currently available for the interactive real-timecommunication session; and wherein transmitting the emulator applicationoccurs in response to determining that the interactive session resourceis not currently available.
 3. The method of claim 1, furthercomprising: before transmitting the emulator application, determiningthat the emulator application is not installed on the requester endpointdevice.
 4. The method of claim 3, further comprising: beforetransmitting the emulator application, receiving consent for theemulator application from a user of the requester endpoint device. 5.The method of claim 1, wherein the new instructions direct the emulatorapplication to present a plurality of locally stored media segmentspending availability of an interactive session resource for theinteractive real-time communication session.
 6. The method of claim 5,wherein the plurality of media segments includes at least one of a groupcomprising music-on-hold, an estimate of wait time, marketing messages,and product information messages.
 7. The method of claim 1, wherein theevent comprises the requester endpoint device establishing anothercommunication session and wherein the new instructions direct theemulator application to display a message to a user of the requesterendpoint device.
 8. The method of claim 7, wherein the message indicatesthat a position of the user in a queue for an interactive sessionresource for the interactive real-time communication session will not beaffected by the event.
 9. The method of claim 7, wherein, during theother communication session, the new instructions direct the emulatorapplication to present the user with an option to participate in theinteractive real-time communication session when an interactive sessionresource for the interactive real-time communication session becomesavailable.
 10. A system comprising: one or more processors, and one ormore memory devices operatively coupled to the one or more processorsand storing program instructions therein, the one or more processorsbeing configured to execute the program instructions that direct the oneor more processors to: receive a request at a server, from a requesterendpoint device, to initiate an interactive real-time communicationsession, wherein the request was transferred in response to user inputinto a browser executing on the requester endpoint device; afterreceiving the request, transmit an emulator application to the requesterendpoint device, wherein the requester endpoint device executes theemulator application; receive a report of an event detected by theemulator application on the requester endpoint device; and in responseto the event indicating new instructions should be sent, update theemulator application with the new instructions, wherein the emulatorapplication is updated to carry out the new instructions.
 11. The systemof claim 10, wherein the program instructions further direct the one ormore processors to: in response to receiving the request, determine thatan interactive session resource is not currently available for theinteractive real-time communication session; and wherein transmittingthe emulator application occurs in response to determining that theinteractive session resource is not currently available.
 12. The systemof claim 10, wherein the program instructions further direct the one ormore processors to: before transmitting the emulator application,determine that the emulator application is not installed on therequester endpoint device.
 13. The system of claim 12, wherein theprogram instructions further direct the one or more processors to:before transmitting the emulator application, receive consent for theemulator application from a user of the requester endpoint device. 14.The system of claim 10, wherein the new instructions direct the emulatorapplication to present a plurality of locally stored media segmentspending availability of an interactive session resource for theinteractive real-time communication session.
 15. The system of claim 14,wherein the plurality of media segments includes at least one of a groupcomprising music-on-hold, an estimate of wait time, marketing messages,and product information messages.
 16. The system of claim 10, whereinthe event comprises the requester endpoint device establishing anothercommunication session and wherein the new instructions direct theemulator application to display a message to a user of the requesterendpoint device.
 17. The system of claim 16, wherein the messageindicates that a position of the user in a queue for an interactivesession resource for the interactive real-time communication sessionwill not be affected by the event.
 18. The system of claim 16, wherein,during the other communication session, the new instructions direct theemulator application to present the user with an option to participatein the interactive real-time communication session when an interactivesession resource for the interactive real-time communication sessionbecomes available.
 19. A computer-readable storage medium having programinstructions stored thereon, the program instructions, when executed byone or more processors, direct the one or more processors to: receive arequest at a server, from a requester endpoint device, to initiate aninteractive real-time communication session, wherein the request wastransferred in response to user input into a browser executing on therequester endpoint device; after receiving the request, transmit anemulator application to the requester endpoint device, wherein therequester endpoint device executes the emulator application; receive areport of an event detected by the emulator application on the requesterendpoint device; and in response to the event indicating newinstructions should be sent, update the emulator application with thenew instructions, wherein the emulator application is updated to carryout the new instructions.
 20. The computer-readable storage medium ofclaim 19, wherein the program instructions further direct the one ormore processors to: in response to receiving the request, determine thatan interactive session resource is not currently available for theinteractive real-time communication session; and wherein transmittingthe emulator application occurs in response to determining that theinteractive session resource is not currently available.